[win][aarch64] Fix linking statics on Arm64EC, take 2

Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
          C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```

It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.

The fix is to have Rust not prefix statics with `#` when importing.

Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.

Fixes #138541

Resurrects #140176 now that #141061 is merged, which removes the incompatibility with `__rust_no_alloc_shim_is_unstable`.

r? `@wesleywiser`

CC `@bjorn3`
try-job: x86_64-msvc-

[win][aarch64] Fix linking statics on Arm64EC, take 2

Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
          C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```

It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.

The fix is to have Rust not prefix statics with `#` when importing.

Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.

Fixes #138541

Resurrects #140176 now that #141061 is merged, which removes the incompatibility with `__rust_no_alloc_shim_is_unstable`.

r? `@wesleywiser`

CC `@bjorn3`

--

try-job: x86_64-msvc-*
try-job: x86_64-mingw-*
try-job: dist-aarch64-msvc

[win][aarch64] Fix linking statics on Arm64EC, take 2

Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
          C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```

It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.

The fix is to have Rust not prefix statics with `#` when importing.

Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.

Fixes rust-lang#138541

Resurrects rust-lang#140176 now that rust-lang#141061 is merged, which removes the incompatibility with `__rust_no_alloc_shim_is_unstable`.

r? `@wesleywiser`

CC `@bjorn3`

Rollup of 8 pull requests

Successful merges:

 - #140622 (compiletest: Improve diagnostics for line annotation mismatches)
 - #142641 (Generate symbols.o for proc-macros too)
 - #142695 (Port `#[rustc_skip_during_method_dispatch]` to the new attribute system)
 - #142742 ([win][aarch64] Fix linking statics on Arm64EC, take 2)
 - #142894 (phantom_variance_markers: fix identifier usage in macro)
 - #142928 (Fix hang in --print=file-names in bootstrap)
 - #142930 (Account for beta revisions when normalizing versions)
 - #142932 (rustdoc-json: Keep empty generic args if parenthesized)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup of 7 pull requests

Successful merges:

 - #137268 (Allow comparisons between `CStr`, `CString`, and `Cow<CStr>`.)
 - #142704 (Remove the deprecated unstable `concat_idents!` macro)
 - #142742 ([win][aarch64] Fix linking statics on Arm64EC, take 2)
 - #142843 (Enable reproducible-build-2 for Windows MSVC)
 - #142916 (rustdoc-json: Add test for `#[optimize(..)]`)
 - #142919 (rustdoc-json: Add test for `#[cold]`)
 - #142944 (Stats output tweaks)

Failed merges:

 - #142825 (Port `#[track_caller]` to the new attribute system)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #142742 - dpaoliello:arm64eclinking, r=bjorn3

[win][aarch64] Fix linking statics on Arm64EC, take 2

Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
          C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```

It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.

The fix is to have Rust not prefix statics with `#` when importing.

Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.

Fixes #138541

Resurrects #140176 now that #141061 is merged, which removes the incompatibility with `__rust_no_alloc_shim_is_unstable`.

r? ``@wesleywiser``

CC ``@bjorn3``